[レポート] JetBlue社のSnowflakeとdbtによるニアリアルタイムデータ配信 #SnowflakeSummit

大阪オフィスの玉井です。

日本時間の2021年6月9日～10日に、Snowflake Summit 2021が開催されました。

当記事では、Snowflake Summit 2021のセッションの中から、 Delivering Near Real-time Data at JetBlue with Snowflake and dbt（JetBlue社のSnowflakeとdbtによるニアリアルタイムデータ配信）のレポートをお届けします。

概要

Airlines can succeed or fail based on how they respond in a snowstorm. For JetBlue, that means that data infrastructure not only needs to help business leaders make long-term decisions; it also needs to help crew members in the System Operations team make high-pressure decisions that require near real-time data. In this session, you’ll learn how the teams at JetBlue adopted a modern data engineering strategy using Snowflake and dbt to deliver near real-time data pipelines that meet the company's needs.

航空業界において、ニアリアルタイムにデータを把握することは、非常に重要です。難易度としては比較的高い「ニアリアルタイムなデータ配信」の仕組みを、Snowflakeとdbtを使って、効率的に構築した話を伺うことができます。

セッションレポート

※レポート本文のみ、一人称は登壇者を指します。

前段

今日は、jetBlue社での経験と、dbtとSnowflakeを使って、データ分析をリアルタイムで利用できるようにするという問題を解決したことについてお話しできることをとても嬉しく思います。

まず、自己紹介から始めましょう。私の名前はBen Singletonです。JetBlueでデータサイエンス・アナリティクスのディレクターをしています。私はいくつかのチームを管理していますが、そのうちの1つがデータエンジニアリングチームで、データをクラウドに統合したり、データを管理して、お客様に効率的、効果的、かつ素晴らしいビジネスを提供するために必要なすべてのデータ要素を提供することに重点を置いています。

また、このプレゼンテーションの途中でAshley Van Nameが登場したら、彼女に自己紹介をしてもらいます。Ashleyは当社のデータエンジニアリングチームを率いています。

ご存知の方もいらっしゃるかもしれませんが、jetBlue社はニューヨークの地元の航空会社として知られています。jetBlue社は20年以上の歴史があり、今日はそのストーリーを皆さんと共有できることをとても嬉しく思っています。そして、もうすぐヨーロッパにも就航することをお伝えしたいと思います。

データドリブンな航空会社とは？

私がjetBlue社に入社した約1年半前にさかのぼりますが、その時、私は当社の戦略に役立つ質問をしなければなりませんでした。それは、「今の時代、データドリブンな航空会社は20年後にはどのようになっているべきか」というものでした。

お客様にjetBlue社を選んでいただけるような体験を提供することに重点を置いた、データドリブンな航空会社の真の指針となる原則がいくつかありました。その「体験」というのは、小さなことから大きなことまで、様々なものがあります。個人的な挨拶、最近ご利用いただいた旅行へのお礼、（お客さんが）期待していた体験ではなかった場合のお詫び、などです。このように、jetBlue社は、過去20年間、飛行機を飛ばすだけでなく、顧客サービスを提供する会社であることを誇りにしています。

航空会社を運営する上でもう一つ重要なのは、データのオペレーションです。航空会社の経営は、オーケストラの指揮に似ています。常に何百もの部品が動いており、1日に何百、何千ものフライトをこなすのは本当に複雑な問題で、データを使ってその問題を解決する必要があります。もちろん、他の企業と同様に、この種の問題には常に目を光らせていなければなりません。また、必ずしもこの2つのカテゴリーに当てはまらない問題も数多くあり、それらにも取り組んでいかなければなりません。私たちは、人材や多様性、公平性、インクルージョンの問題に関心があり、それらに関するデータを把握したいと考えています。

私たちは、財務に関する情報をもっと知りたいのです。もちろん、一番の基本は安全性であり、お客様にとって非常に安全な航空会社であることを目指しています。そのためには、アナリストが必要なデータにアクセスできるようにしなければなりません。すべてのユースケースを事前に考えておくことはできませんから、私たちが支え手になって、このプラットフォームを提供しなければなりません。

リアルタイムでの意思決定も非常に重要です。航空会社は、「吹雪の中で自分の力を発揮できるかどうか」という言葉がありますよね。突然、嵐がきたら？突然、予期せぬ問題が発生したら？私たちは迅速に対応し、お客様が最初に来て選んでくれた目的地に確実に連れて行かなければなりません。

どうすればデータドリブンな航空会社になれる？

では、どのようにすれば、今まで話してきたことを実現できるのでしょうか？結局のところ、多くの企業がそうであるように、私たちもデータに基づいた意思決定をしなければなりません。データはすべての意思決定に反映されなければなりません。私は社内で「分析的な質問には15分以内に答える」という言葉を使ってきました。会議中に質問があった場合、あなたやアナリストは、その質問にほぼ即座に答えるべきです。そうでなければ、当たり前で、ためにならない結論で終わってしまいます。結局、自分の直感に頼ってしまう…たとえ状況が変わっていても、データが違う方向に導いてくれるはずなのに、去年と同じことをしてしまうのです。

第二に、先に述べたように、これらの質問には、データの専門家であるチームが答えなければなりません。彼らは、データが利用可能であることを知り、これらの質問に答えることができるツールやトレーニングを持っていることをセルフサービスで知る必要があります。データへのニーズは爆発的に高まっており、新しいツールやプラットフォーム、製品を発売するたびに、膨大なデータの宝庫となっています。

そして、パートナーやビジネス全体のステークホルダーが必要とするデータセットを迅速に構築する能力を確実に拡大していかなければなりません。そうしないと、お客様は当社の能力やサポート能力を信頼しなくなってしまいます。そのためにはプラットフォームが必要です。

当社では、約1年半前にSnowflakeの利用を開始しましたが、これが大きな変化をもたらしました。

jetBlue社のデータ分析における課題

さて、私たちが解決しようとしていた問題に話を戻したいと思います。次のスライドでお話しするのは、皆さんの多くが共感できるストーリーだと思っています。多くの企業が直面している問題でもあります。これは、オンプレミスで構築したデータスタックを真にモダナイズし、今後5年、10年、さらに未来に向けて有効にしようとしている企業の話です。

それでは、これらの問題点を順を追って説明していきたいと思います。

そのどれもが、時には苦痛を伴うこともありました。そして、これらの問題を解決しようとしていたユーザーによって、ある意味ではどれも同じくらい重要なのです。そこでまず、データディスカバリーについてお話したいと思います。

jetBlue社には、IT部門がサポートする何百ものシステムがあります。これらのシステムの多くはデジタルデータを持っており、最終的には当社のデータスタックで利用できるようにしたいと考えています。しかし、すべてのテーブルやカラムの意味を正確に知ることは本当に難しく、私たちがサポートできることではありませんでした。例えば、搭乗者数といっても、実際には何を意味しているのでしょうか？パイロットやクルーを含めた乗客の数でしょうか？座席に座っている乳幼児はどうでしょうか？座席に座っている乳幼児はその数に含まれるのでしょうか？一見、当たり前のように見えるカラムやデータポイントにも、色々なニュアンスが含まれる場合があり、アナリストがその点について正確な情報を得られるようにする必要があります。

第二に、データウェアハウスに送られてくるデータは、これまでエンドユーザーには分かりにくい変換を経ていました。これを「Blackbox Transformation」と呼ぶこともあります。私たちは、この情報をエンドユーザーに公開し、データが最終的にどのようにクエリやダッシュボードのテーブルに配置されたかを知ってもらいたいと考えました。そのため、このプロセスの一環として、より透明性を高めなければなりませんでした。

私たちがオンプレミスで使用していたデータウェアハウスは、親しみを込めて「パート従業員」と呼んでいました。このデータウェアハウスは、特定の製品を購入した時に企業が作成した爆発的なデータの関心に対応するための適切なリソースがありませんでした。その結果、データの読み込みには何時間もかかり、同時にクエリを実行することができませんでした。それと同時に、データの変換も行われていました。

その結果、毎晩何時間もデータウェアハウスをアナリストが利用できない状態にしなければなりませんでした。多くのお客様がそうであるように、私たちも24時間365日体制で業務を行っていましたが、これは最終的に受け入れられませんでした。データが常に意思決定に役立つことを保証しようとしているときにです。

次に、クエリ自体のパフォーマンスが低下していました。私たちが使用していたアプライアンスの一部は、同時実行可能なクエリの数が限られていました。また、ある時間に、3番目にクエリを実行した人で、前のクエリが実行されていた場合、その分のコストがかかっていました。何分も、時には何時間も、結果が出るのを待つことになるかもしれません。分析に関する質問には15分以内に回答するというモットーを守るためには、これではいけません。これは結局、受け入れられないことになります。

自分自身を振り返り、何が自分の課題なのかを認識する必要がありました。私たちは小さなチームです。jetBlue社は何千人もの従業員を抱える大企業ですが、私たちのデータエンジニアリングチームは、従業員全員がより良い意思決定を行えるようにすることを目的とした、ごく少数の人たちです。

そこで私たちは、シャドーITの可能性を制限したいと考えました。関係者の一部が、ガバナンスやITの指示によらずにデータ問題を解決しようとする可能性があったからです。しかし、これには限界があることを認識しなければなりませんでした。そのため、小さくても強力なチームをサポートするツールやプラットフォーム、インフラを選ぶ必要がありました。そして最後に、私たち自身を振り返ってみると、私たちが課題に関する専門家になったことを認識しています。様々なデータソースに精通しているのは当然のことです。しかし、最終的には私たちは課題に関する専門家ではありませんでした。会社全体の特定のリーダーと、それを熟知している分析の専門家がいたのです。

また、他のチームのアナリストが、データの性質に関する具体的な質問に答えるために訪れる場所になってしまうと、それがボトルネックになってしまうことに気づきました。そこで私たちは、データエンジニアリングチームの負担を軽減するために、どのように組織を編成し、どのようなプラットフォームを選択すればよいのかを検討する必要がありました。

最後に、今日のプレゼンテーションの焦点なのですが、リアルタイムデータの問題があります。

前置きが長くなりましたが、航空会社では、吹雪が近づいてきたとき、雷雨が近づいてきたとき、突風が吹いてきたとき、急にスケジュールを変更しなければならなくなったときに、素早く決断することが絶対に重要です。それも、オペレーション上の摩擦をお客様に感じさせないようなシームレスな方法で行いたいのです。そのためには、テーブルやビューを作成し、最終的にはこのようなリアルタイムの意思決定を可能にするリアルタイムアラートやダッシュボード、レポートをサポートする必要がありました。

これまでは、エンドユーザーにリアルタイムデータを公開することができませんでした。これは、みなさんの組織でも同じような理由があるかもしれません。多くの場合、リアルタイムシステムに多くの負荷をかけることは大きな課題となります。そこで、Snowflakeを使えば、こうしたニーズに対応できるのではないかと考えました。この点については、後ほど詳しく説明します。

最後に、安全性は当社の第一の価値であるため、データセキュリティは常に念頭に置いています。お客様の情報を保護する必要があります。企業秘密や事業に関する重要な情報を保護する必要があります。そのためには、データセットの機密部分を保護しながら、データへのアクセスを確実に拡大する必要があります。そのために、データのマスキングやその他のセキュリティ管理を行っています。今後、私たちは絶対に頭の片隅に置いておかなければなりませんし、中心に置かなければなりません。

さて、私たちはどこへ行こうとしているのでしょうか？何度もお話ししたように、私たちは結局、「Snowflake」、つまりデータクラウドを、この最新のインフラの中心的な部分として選びました。

Jetblue社の新しいデータ分析基盤

これは、すべてのデータを保存し、また、すべてのデータ変換を行うための核となるものです。アナリストが日常的に使用するツールになります。また、BIツールなどが、多くのデータを最終的なインサイトに変えるために接続する必要があるプラットフォームになるでしょう。そのため、従来のMicrosoft SQLのオンプレミス・スタックから、Snowflakeを前面に押し出したスタックへと移行しました。

そして、もうひとつのツール、dbtについてもご紹介します。dbtはData Build Toolの略です。これはFishtown Analytics社が開発した製品で、Snowflakeの中でデータの変換を行うことができ、先ほど取り上げた問題の多くを実現することができます。それでは、このリアルタイムデータの問題を解決するために、Ashleyに詳細を説明してもらいます。

リアルタイムなデータをSnowflakeに格納する仕組み

皆さん、こんにちは。jetBlue社でデータ・エンジニアリング・チームを管理しているアシュリーと申します。カンファレンスの講演で私が一番好きなのは、誰かが自分の現在の目的のために実際にどのように構築したかを説明するときです。今回は、Snowflakeにニアリアルタイムでデータをロードするためのソリューションをどのように実装したかをお話しできることをとても楽しみにしています。

まず最初に、ニアリアルタイムのデータが、どのようにして今日のような事態を引き起こすのか説明したいと思います。もちろん、あらゆるリアルタイムフィードの主要な構成要素は、メッセージストリームにメッセージを書き込むきっかけとなる何らかのアクションやイベントです。

当社では、社内外のイベントドリブン型アプリケーションを組み合わせて、業務中に発生するイベントを捕捉しています。これらのイベントは、航空機が離陸するときやゲートに到着するとき、お客様がウェブサイトで予約をするとき、お客様が空港でバッグタグを印刷するときなどに発生します。これらのアクションはすべて、リアルタイムのイベントストリームによってキャプチャされ、アプリケーションによって処理されます。これらのメッセージのコピーは、通常はAzureのストレージに書き込まれ、JSON形式で時間分割されたフォルダに保存されます。

このデータストレージ構造により、Snowflake内のメッセージ配信時のタイムスタンプに基づいてイベントを簡単に検索し、処理することができます。このTaskは、時間別に分割されたblobストレージのフォルダから、rawデータベースとAnalyticsデータベースと呼ばれるものにデータをコピーします。rawデータベースは、すべてのイベントデータを最も純粋な生の形で保存します。

このデータを分析に使うためには、アナリストが使いやすい形にデータを変換する作業が必要です。先ほどBenが言ったように、私たちはdbtというツールを使っています。dbtは基本的に、rawデータに対して簡単なSQLを書くことができ、その結果を下流のテーブルやビューに具体化して、関係者が利用できるようにします。

他のデータエンジニアリングのワークフローと同様、私たちにとっての「悪魔」は、常に細部に宿っています。これらの詳細は、3つの主要コンポーネントに分散しています。

最初の主要コンポーネントは、前回のスライドで述べたように、タイムパーティションのデータストレージです。これはどのようなものなのでしょうか？非常にシンプルなコンセプトだと思います。基本的には、新しいイベントを受信するたびに、ストレージにメッセージを書き込み、現在のタイムスタンプ（UTCの年、月、日、時、分）に対応するフォルダ別に格納します。

タイムパーティション・データストレージを構築することで、個別に処理できるデータファイルのグループを分離し、定期的にcopy intoコマンドを実行してrawデータをSnowflakeテーブルにロードすることができます。大量のメッセージを送信するデータフィードには、タイムパーティショニングが不可欠です。外部ステージにあるファイル数が非常に多い場合、copy intoコマンドでは処理できないからです。そこで、シンプルなJavaScriptのストアドプロシージャを記述することで、copy intoコマンドが操作する必要のある各タイムパーティションフォルダを動的に定義することができました。これにより、copy intoコマンドがストレージコンテナ内の何百万ものファイルをスキャンするのを待つことなく、ほぼリアルタイムのデータを素早くロードすることができるようになりました。

リアルタイムアーキテクチャの最後の重要なコンポーネントは、「Lambda View」と呼ばれるものです。Lambda Viewは、その名が示すように、新鮮なデータがデータベースにSnowflakeのように届くと同時に、エンドユーザーに公開することができます。基本的にLambda Viewは、毎時間更新されるテーブルと、過去に受信した最新のデータを公開するビューを組み合わせたものです。

次に、これらのコンポーネントの一つ一つを掘り下げて、実際にどのように動作するかの例をお見せしたいと思います。

リアルタイムデータの活用例

当社のリアルタイムイベントを説明するために、次のシナリオを考えていただきたいと思います。

朝6時に起きて、jetBlue社のカリブ海行きの飛行機に乗りたいと決断したとします。jetBlue社のウェブサイトにアクセスして、アルバ行きのフライトの予約をします。予約が作成されるとすぐに、新しい予約とチケットが処理されたという通知が届き、その情報がタイムパーティションのストレージフォルダに書き込まれます。この例では、メッセージがcontainer/2021/05/10/07/00/event_1.jsonという形で保存されていることがわかります。

1分後、SnowflakeのTaskが落ち、そのタイムパーティションフォルダのデータが、まだSnowflakeにコピーされていないことを認識するストアドプロシージャが実行されます。数秒後、copy intoコマンドが成功すると、最新の予約情報がSnowflakeのデータベースに入ります。

数時間後、そろそろ飛行機に乗る時間になり、空港に到着すると、セルフサービスのキオスクやクルーのいるデスクで、チェックインやバッグタグの印刷をすることができます。いずれにしても、お客様のチェックインが完了し、バッグタグが印刷されると、タイムパーティションのブログフォルダに書き込まれた別のイベントセットが再び受信されます。同じくスケジュールされたcopy intoのTaskによって、これらのメッセージがデータベースに読み込まれ、データが、下流のビューやテーブルに表示され、ユーザーがさらに分析できるようになります。この時点で推測できるように、飛行機が離陸すると、すぐに、あなたが向かっていることを伝えるメッセージを受け取ることになるでしょう。

ここまでで、ほぼリアルタイムのデータをSnowflakeに取り込む方法と、そのデータを分析者に公開するためにLambda Viewが実際に機能することを説明しました。

この図は、私たちがどのようにデータの取り扱いをしているかを正確に説明しています。

私たちは、1時間ごとに更新されるテーブルを含むフローを構築し、テーブルが最後に更新された後にrawデータベースに追加されたすべてのデータを公開するために、それをビューに結合しました。この結合の出力は、Snowflakeの単一のビューまたは他のLambda Viewであり、これは与えられたデータフィードの最新情報のシングルソースとして機能し、関係者がレポートや分析のために、簡単に使うことができます。

しかし、このようなリアルタイムでのデータの取り込みや公開は、dbtというツールがなければ実現できません。dbtのおかげで、データとSnowflakeのほぼリアルタイムのビューを光速で構築することができました。

dbt

dbtとは何か、そして私たちの組織でどのように使用しているかについて正確にお話ししたいと思います。先ほどBenが言ったように、dbtはウェブサイト上ではData Build Toolの略です。「ELTワークフローのT」という表現を目にすることがあります。これは、Snowflakeに読み込まれたrawデータと対話するためのツールで、エンジニアはそのデータをより使いやすい形に変換するための軽量なSQLを素早く書くことができます。私たちが考えるコア機能とは、SnowflakeにSQLの形でデータ変換命令を送るツールです。

Snowflakeは当然ながら、データを変換するという大変な作業を担います。しかし、データをどのように変換すべきかという指示は、すべてSnowflakeに保存されることになります。これは、データ変換のためのSQLに慣れているチームがある場合には特に便利です。

Lambda Viewの構築

dbtを使ってできることは山ほどあります。しかし、このプレゼンテーションでは、dbtを使ってLambda Viewを構築する方法を説明することに集中したいと思います。また、前置きが長くなりましたが、技術的には、これらすべてがdbtが無くても実現できるものです。しかし、私たちの意見としては、DDLやDMTのスクリプトをすべて自分たちで書くよりも、（dbtの方が）これらのフローをより早く構築し、より簡単にメンテナンスすることができると考えています。dbtを使えば、他のモデルの参照、設定、マージや削除、アップデートの挿入、データテーブルの完全な再構築などを、必要に応じて非常に簡単に行うことができます。

最初のステップは、ソースから受け取った生の形のデータを保存するテーブルとデータベースにすでに作成しておくことです。この情報は、SnowflakeのTaskによって読み込まれます。そのrawデータの上に、Snowflakeの中のビューである2つのモデルを構築します。ビューの1つは、rawデータテーブルに存在する生のJSONデータをすべて公開し、フラット化します。もう1つのビューは、同じデータの「限定的なrawビュー」と考えられ、過去24時間にrawテーブルに追加された生のJSONを入れ、フラット化しています。

さらに、私たちはLambda Viewの2つの主要なコンポーネント、「History Table」と「Current View」を構築するために（dbtを）使用しました。History Tableは1時間ごとに更新されるようにスケジュールされており、過去1時間にrawデータベースに追加及びフラット化されたデータをすべて挿入します。そして、History Tableに固有のCurrent Viewは、1時間ごとのジョブの間にrawデータベースに到着したデータを公開し、フラット化します。この2つをUNIONしたものは、アナリストが使用できる単一のエントリーポイントを作成し、ほぼリアルタイムのデータなどを扱うことができます。

Lambda Viewを選んだ理由

他にも選択肢があったのに、なぜLambda Viewを使ってこのような半端に複雑なワークフローを構築したのか、という疑問があるかもしれません。

リアルタイムに近いデータをエンドユーザーに公開するには、Lambda Viewが最も費用対効果の高い方法だと考えました。例えば、通常のビューを使ってすべてのリアルタイムデータを公開することもできたでしょう。しかし、ビューの処理に時間がかかりすぎてしまい、社内のSLAを満たすことができませんでした。また、マテリアライズド・ビューを使用するという選択肢もありましたが、マテリアライズド・ビューでは変換できる範囲が限られていることや、コスト削減を重視していたことから、マテリアライズド・ビューを使用しないことにしました。これは、私たちにとって最良の選択肢ではないと思いました。

次に、テーブルの更新をマイクロバッチで実行する方法を考え始めましたが、すぐにそれも良い方法ではないことに気づきました。トランスフォーメーション・ウェアハウスを24時間365日稼働させる必要があり、それにはコストがかかります。

そこで最終的にたどり着いたのがLamda Viewでした。このLamda Viewがあれば、このほぼリアルタイムのデータをエンドユーザーのメーターSLAに表示し、コストを削減することができます。

実際のところどうなるのか

ここで、私たちのリアルタイムデータ統合が実際にどのように行われているかを紹介したいと思います。

現在、私たちは1つの特別な小さな仮想ウェアハウスをプロビジョニングしています。この仮想ウェアハウスは1〜8のクラスターにスケールし、現在は30以上のリアルタイムデータ統合をサポートするために使用されています。このような構成であれば、Snowflakeにデータをロードするためのコンピュートコストは比較的安価になります。

メッセージのスループットはフィードによって異なりますが、大容量のフィードの中には、既存のデータ取り込みパイプラインを使ってSnowflakeに追加される1つのフィードで、1分間に約300のメッセージが表示されるものもあります。過去のデータを調べてみたところ、数週間前には1つのフィードに対して1分間に7000通以上のメッセージが追加されていました。この方法はうまくいき、必要なメッセージのスループットに合わせて拡張することができます。

最後に、このアプローチと構成により、内部SLAの範囲内で十分な待機時間が得られることがわかりました。平均して、メッセージが（データ発生元の）システムで作成されてからSnowflakeにロードされるまでに約1.3分かかることがわかりました。1回のフィードで観測されたSnowflakeまでの最速時間は約13秒でした。

dbtでLambda Viewを構築する中で学んだこと

リアルタイムに近いデータをSnowflakeに取り込むためのパイプラインを構築する過程で、多くのことを学びましたが、中でもスライドに表示されている4つの項目が最も重要だと考えています。

まず1つ目は、データのサイズによっては、Lambda Viewでは遅すぎる可能性があるということです。組織内でLambda Viewの構築を計画している場合は、データを絞り込んで、その場で変換する必要のある情報量を制限する方法を検討し、考える時間を取るべきです。ユーザーがクエリを実行する際、データのフィルタリングを進めれば進めるほど、結果が早く返ってくるようになり、ウェアハウスのコンピュートにかかる費用を節約することができます。

データがUTCに基づいてタイムパーティショニングされていることを確認する必要があります。これにより、タイムゾーンの違いによる問題や、最終的なサマータイムのシフトなど、データエンジニアリングのワークフローにタイムゾーンを導入する際に生じる複雑な問題を回避することができます。

すべてのrawデータテーブルには、メタデータ情報を含まなければならないというポリシーを導入することも非常に有効でした。これには、ファイル名、ファイルが生データテーブルに挿入された時間、そして該当する場合はソースファイル内のレコードの生の番号などが含まれます。このメタデータ情報は下流のテーブルにも引き継がれ、データの問題が発生したときにトラブルシューティングをする際に非常に役立ちます。

リアルタイムデータ取り込みスクリプトには、取り込みフィードに何らかの問題が発生した場合に、あらゆる時間のパーティションに追いつく能力があることが不可欠です。これはTaskに組み込まれた自己修復メカニズムであり、Taskがデータ読み込み時にファイルをスキップすることなく、すべてのタイムパーティションで実際にすべてのデータをキャプチャしていることに大きな自信を与えてくれます。

まとめ（Jetblue社が取り組んだ理由）

分析のためにリアルタイムデータを公開するためのパイプラインとデータモデルをどのように構築したか、ということを説明してきましたが、実際にこのようなことに時間を費やすのはなぜでしょうか？それは、Snowflakeへのニアリアルタイムのデータ取り込みと、dbtを使ったニアリアルタイムのデータ公開を実装したことで、組織全体の意思決定を支援するデータ製品を構築できるようになったからです。

例えば、経営陣は今、手のひらの上で業務全体のパフォーマンス指標をほぼリアルタイムで見ることができます。また、私たちのネットワーク全体でフライトの乱れや遅れを監視するチームもあり、お客様が一刻も早く最終目的地に到着できるようサポートしています。

私たちは、業界とお客様が過去1年間に経験したすべてのことを考慮し、パンデミックの際にはデータを利用してお客様の体験を改善する方法を常に模索しています。私たちは、ニアリアルタイムで提供されるお客様のデータとSnowflakeを利用してソーシャルディスタンシングダッシュボードを作成し、乗務員がフライト中のお客様の間隔を空ける機会を特定できるようにしました。これらは、Snowflakeのニアリアルタイムのデータを利用して社内の意思決定を支援するための数多くのユースケースのうちの3つに過ぎません。

今後、月日が経つにつれて、エンドユーザーが、ほぼリアルタイムのデータを重要な要素として、組織全体で構築していく未来の製品を、私たちはとても楽しみにしています。

おわりに

「データはすべての意思決定に反映されなければならない」

ここまで言い切れる企業、どのくらいあるでしょうか。話の中にもあった通り、「飛行機で人を運ぶ」というビジネスにおいて、決断の品質とスピードは、かなり高いものが求められると思います。そんな中で、Snowflakeに全てのデータを連携して、dbtを使ってデータを使いやすい形に変換する取り組みを行っているのは、相当先進的です。

また、Lambda Viewという取り組みが面白かったです。データ分析において、ニアリアルタイムなデータ連携というのは、昨今よく課題に挙がっていますが、その中の解決方法の1つとして、ぜひ検討したい手法です。ちゃんと、この手法に至る経緯と理由も話されていたのが、非常に良いですね。

参考

関連する話が、dbtコミュニティにもあったので、記載しておきます。